Is there a way we can check the results without pushing the preview?

Is there a way we can check the results without pushing the preview?

No.

We should enable the preview when we want for particular PRs... We don't want previews for every random PR because things will get out of hand.

Is there a way we can check the results without pushing the preview?

Also I don't think we should use the example to assess PRs, they take way too long to run. We have a lot of development to do so we need a way to assess PRs more quickly...

We can put problems that are similar to the example (but cheaper) in the tests, and create plots from them if we want (ClimaAtmos does something similar).

Codecov Report

Attention: Patch coverage is 0% with 74 lines in your changes missing coverage. Please review.

Project coverage is 0.00%. Comparing base (8796b45) to head (7ceabae).
Report is 1 commits behind head on main.

@@          Coverage Diff          @@
##            main    #156   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files         31      32    +1     
  Lines       1739    1779   +40     
=====================================
- Misses      1739    1779   +40     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Is there a way we can check the results without pushing the preview?

No.

We should enable the preview when we want for particular PRs... We don't want previews for every random PR because things will get out of hand.

An alternative though is if @simone-silvestri wants to take responsibility for deleting the old push previews right?

Do you mean deleting the previews after the PR is merged? That could be a nice idea. Maybe we can merge this PR and I can investigate if it is possible to do this in an automatic manner

Do you mean deleting the previews after the PR is merged? That could be a nice idea. Maybe we can merge this PR and I can investigate if it is possible to do this in an automatic manner

We already attempt to do it automatically, but it doesn't always work. So previously, @navidcy took responsibility for monitoring the repo and going in and manually deleting things when it filled up (similar to what I do with the buildkite builds). But @navidcy eventually decided it was too much work. However you can decide to take this responsibility if you want to keep the previews. I don't think you'll be able to completely automate the process.

Ok, I can take responsibility for that and see how it goes.

There is a way to do it automatically if the gh-pages are in the same repo. It's documented in the documentation of Documenter.jl and actually the example there is from a CliMA repo!! However, it doesn't work for when the Docs live in a different repo. I tried a lot and also asked CliMA to help me to make it work for when the docs are deployed in a different repo but I never managed to do it. If you figure how to do that it'd be great!!

Btw, why are the examples still haven't run?

https://buildkite.com/clima/climaocean-examples/builds/355

??

The Run examples label triggers the build, without that the examples are not run. I have added the label but you have to commit again to trigger the pipeline

https://buildkite.com/clima/climaocean-examples/builds/356#019176f1-b195-44bb-8114-d68491646a86/207-1012

Are the files id Dropbox still there?

I don't think they were deleted. maybe restarting the build will download them correctly?

ERROR: LoadError: LoadError: Number of threads per block exceeds kernel limit (1024 > 896).
in expression starting at /central/scratch/esm/slurm-buildkite/climaocean-examples/729/climaocean-examples/docs/src/literated/near_global_ocean_simulation.md:2
when executing the following code block from inputfile /central/scratch/esm/slurm-buildkite/climaocean-examples/729/climaocean-examples/examples/near_global_ocean_simulation.jl

date = DateTimeProlepticGregorian(1993, 1, 1)
set!(ocean.model, T=ECCOMetadata(:temperature; dates=date), S=ECCOMetadata(:salinity; dates=date))

https://buildkite.com/clima/climaocean-examples/builds/729#0192e4d0-1ff4-4c6d-9570-c163ce343a40/189-1417

Any idea what that is and how to avoid it? On tartarus that line went through fine!

I have some progress!

julia> Tn
Observable(1440×600×1 Field{Center, Center, Center} on ImmersedBoundaryGrid on CPU
├── grid: 1440×600×40 ImmersedBoundaryGrid{Float64, Periodic, Bounded, Bounded} on CPU with 7×7×7 halo
├── boundary conditions: FieldBoundaryConditions
│   └── west: Periodic, east: Periodic, south: ZeroFlux, north: ZeroFlux, bottom: Nothing, top: Nothing, immersed: ZeroFlux
├── indices: (:, :, 40:40)
└── data: 1454×614×1 OffsetArray(::Array{Float32, 3}, -6:1447, -6:607, 40:40) with eltype Float32 with indices -6:1447×-6:607×40:40
    └── max=31.2508, min=-1.96045, mean=0.476186)


julia> heatmap(Tn)

[1626384] signal (11.128): Segmentation fault
in expression starting at REPL[56]:1
Segmentation fault (core dumped)

ERROR: LoadError: LoadError: Number of threads per block exceeds kernel limit (1024 > 896). in expression starting at /central/scratch/esm/slurm-buildkite/climaocean-examples/729/climaocean-examples/docs/src/literated/near_global_ocean_simulation.md:2 when executing the following code block from inputfile /central/scratch/esm/slurm-buildkite/climaocean-examples/729/climaocean-examples/examples/near_global_ocean_simulation.jl

date = DateTimeProlepticGregorian(1993, 1, 1)
set!(ocean.model, T=ECCOMetadata(:temperature; dates=date), S=ECCOMetadata(:salinity; dates=date))

https://buildkite.com/clima/climaocean-examples/builds/729#0192e4d0-1ff4-4c6d-9570-c163ce343a40/189-1417

Any idea what that is and how to avoid it? On tartarus that line went through fine!

I think you need to consider a smaller problem / grid